Several solutions have been proposed to date to allow controllers to manage standalone network hardware devices. For instance, VMware's NSX for Multi-Hypervisor controllers manage hardware VTEP (virtual tunnel end point) devices through the OVSDB protocol. The hardware_vtep OVSDB schema that NSX uses to integrate with the VTEP devices is described at the openvswitch website. This schema uses the table Ucast_Macs_Remote to provide the MAC addresses of end-points in various logical switches, and their corresponding locators (VTEP IPs where the devices terminate VXLAN tunnels).
Two hardware VTEP devices can be two routers operating in Virtual Router Redundancy Protocol (VRRP) configuration. These two routers can be like an L3 switch or a switch-router, which has both switch and routing capabilities. During normal operations, only one VTEP device (i.e., VTEP1 or VTEP2) would be the active VTEP device for the VRRP solution: one of them would report the MAC address of the VRRP router through Ucast_Macs_Local. The NSX controller would propagate this MAC address and the VTEP IP (of the active VTEP device, VTEP1 or VTEP2) to all other VTEP devices connected to the logical switch that has the given VRRP router. The NSX controller would propagate this information through the Ucast_Macs_Remote table.
During failover or other error conditions, both VTEP devices (i.e., VTEP1 and VTEP2) may report the MAC address of the router. In that case, the NSX controller needs to decide which VTEP device is the active one, in order to update the Ucast_Macs_Remote table of all other VTEP devices correctly. Therefore, there is a need for a method for the controller to support such VRRP solutions.